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1  Introduction 

A  compositional  approach  to  protocol  design  and  analysis  is  recognized  as  ad¬ 
vantageous.  We  wish  to  perform  design  decomposition  in  a  way  that  permits 
independent  design  and  verification  of  components,  and  preserves  security  and 
correctness  goals  when  the  components  are  recombined.  There  are  many  dif¬ 
ferent  ways  in  which  composition  can  be  interpreted  and  implemented.  Our 
version  of  composition  applies  to  the  design  of  secure  protocols.  Our  objec¬ 
tive  is  to  extend  verification  techniques  based  on  abstract  encryption  models  to 
protocols  that  incorporate  or  implement  encapsulated  services. 

One  use  for  such  services  is  to  invoke  computations  that  are  not  included 
in  the  vocabulary  of  operations  built  into  the  protocol  specification  language, 
such  as  the  special  operations  of  a  Trusted  Platform  Module  [7]  or  some  other 
specialized  cryptographic  application  interface.  Another  use  is  to  allow  flexibil¬ 
ity  in  the  choice  of  means  to  implement  an  operation.  For  a  public-key  lookup, 
for  example,  there  may  be  two  alternative  services,  one  that  fetches  a  locally 
cached  certificate,  and  another  that  initiates  a  protocol  with  a  directory  server 
to  retrieve  one.  A  service  might  even  establish  a  shared  session  key  between  two 
parties  who  have  already  begun  a  protocol. 

With  encapsulation  of  services,  we  can  create  and  maintain  a  library  of 
services  that  could  be  shared  by  all  protocol  processes  running  on  the  same 
system.  The  service  library  can  be  updated  with  improved  implementations 
without  disturbing  existing  protocols,  and  new  services  can  be  added  at  any  time 
for  use  by  future  protocols.  New  services  can  also  be  used  by  older  protocols  if 
they  extend  older  services,  that  is,  if  their  functionality  is  more  general  or  their 
input  requirements  are  less  strict. 

There  are  two  challenges  in  designing  and  using  services:  first,  to  allow  for 
use  of  services  whose  specific  interfaces  have  not  been  anticipated;  second,  to 
assure  ourselves  that  it  is  safe  to  use  separately  designed  services  when  there 
are  security  as  well  as  functionality  concerns. 

‘This  work  was  supported  by  the  National  Security  Agency  through  US  Army  CECOM 
contract  W15P7T-05-C-F600. 
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Our  “encapsulated  services”  should  be  distinguished  from  “Web  services” 
because  they  can  be  purely  local.  Furthermore,  the  security  objectives  that 
we  wish  to  protect  are  the  traditional  confidentiality  and  authentication  goals 
for  secure  protocols,  rather  than  the  more  specific  access  control,  execution 
history  [2]  or  other  policies  associated  with  Web  services.  However,  we  need  not 
exclude  Web  services  as  an  option  for  implementing  an  encapsulated  service. 
Our  focus  is  on  the  interface  to  a  calling  protocol  and  on  maintaining  the  security 
objectives  of  that  protocol. 

Service  specifications  will  be  expressed  in  a  logical  call-by- contract  form.  An 
algorithm  for  selecting  services  that  satisfy  protocol  requests  is  given.  We  take 
into  consideration  that  a  service  specification  may  include  not  only  functional 
guarantees  but  also  confidentiality  guarantees,  which  we  call  non-disclosure 
agreements  (NDAs).  We  give  some  conditions  under  which  authentication  and 
secrecy  properties  established  in  a  Dolev-Yao  idealized  encryption  context  can 
be  carried  over  to  a  general  service  invocation  context. 

In  the  remainder  of  this  section,  the  formal  modeling  context  is  presented. 
Then,  in  Section  2,  we  give  the  abstraction-binding  technique  that  underlies 
the  selection  algorithm.  In  Section  3,  we  show  how  abstraction  binding  is  used 
to  select  services  in  response  to  requests.  In  Section  4,  we  investigate  how  the 
conventional  Dolev-Yao  techniques  for  verification  of  protocol  security  can  be 
extended  safely  to  this  more  general  context. 

1.1  Modeling  Style 

Protocols  are  modeled  here  as  sets  of  roles,  where  a  role  is  the  trace  of  a  param¬ 
eterized  annotated  strand.  An  annotated  strand,  as  presented  in  [10],  extends 
the  basic  strand  notion  from  [13]  by  labeling  nodes  not  only  with  messages  but 
also  trust  management  formulas. 

Messages  in  this  model  are  elements  of  a  free  message  algebra,  presented 
as  expressions  constructed  from  atoms  of  a  few  sorts  (such  as  key  and  text) 
and  operators  such  as  idealized  encryption  and  pairing.  Formulas  are  logical 
expressions  over  the  same  set  of  atoms.  The  threat  environment  is  a  version  of 
the  Dolev-Yao  attacker  model,  in  which  there  is  a  single  attacker  who  is  assumed 
able  to  intercept  any  message,  and  able  to  decompose  or  construct  messages 
using  the  available  operators,  but  unable  to  encrypt  or  extract  information  from 
encrypted  messages  without  the  appropriate  key.  Models  of  this  kind  have  been 
widely  used  to  analyze  the  vulnerability  of  protocols  to  attacks  such  as  replay 
and  spoofing,  in  which  the  attacker  fools  an  honest  participant  into  revealing 
an  entire  key  or  accepting  a  key  provided  by,  or  previously  compromised  by,  the 
attacker. 

1.2  Strand  Spaces:  A  Brief  Summary 

The  purpose  of  this  summary  is  primarily  to  review  the  vocabulary  used  in  this 
paper.  Most  of  the  details  are  not  necessary  until  we  apply  a  prior  strand  space 
result  in  the  latter  part  of  Section  4. 


2 


A  strand  is  a  sequence  of  nodes.  A  node  has  a  label  (±m,  <f>)  where  ±m 
is  a  directed  (+  for  sent  or  —  for  received)  message,  and  the  annotation  </> 
is  a  formula.  The  atoms  used  in  m  and  </>  are  elements  of  the  disjoint  union 
A  =  X  U  Z  of  parameters  X  and  values  Z.  The  trace  of  a  strand  is  its  sequence 
of  node  labels.  Any  sequence  of  node  labels  may  be  referred  to  as  a  trace.  When 
applied  to  a  trace,  the  term  “node”  refers  to  a  position  in  the  label  sequence. 

A  bundle  is  a  finite  partially  ordered  set  of  nodes,  where  each  node  belongs 
to  a  partial  strand  (an  initial  subsequence  of  a  strand)  and  the  partial  ordering 
combines  the  strand  node  sequence  ordering  (represented  with  =»)  and  a  com¬ 
munication  ordering  — >  that  relates  each  receive  node  to  a  prior  send  node  with 
the  same  message.  All  atoms  occurring  in  a  bundle  must  be  from  Z ,  though 
some  authors  make  use  of  semibundles  in  which  parameters  may  occur,  and 
some  receive  nodes  do  not  have  predecessors  in  the  communication  ordering. 

A  parameter  is  bound  at  a  node  if  it  occurs  in  the  node  label  of  that  node, 
or  of  a  prior  node,  or  (for  any  node)  if  it  is  an  input. 

A  protocol  is  a  set  of  roles.  A  role  is  a  4-tuple  r  =  ( R ,  I,  U,  T)  where  R  is  a 
trace  in  which  all  atoms  are  parameters,  /  is  a  subset  of  parameters  designated 
as  inputs,  U  is  a  subset  of  parameters  designated  as  uniquely  originating ,  and 
T  is  the  initial  theory.  T  consists  of  general  inference  rules  (see  Section  2)  and 
facts  expressible  as  formulas  over  input  parameters. 

There  are  penetrator  roles  that  define  the  attacker  model.  The  penetrator 
roles  do  not  belong  to  any  particular  protocol.  A  penetrator  role  is  one  of  a  few 
specific  types  representing  the  ability  of  the  attacker  to  construct  and  decompose 
messages.  For  example, 


(-fe,T),  (-{*}*, T),(+®,T) 

is  a  penetrator  role  that  performs  decryption,  where  T  is  the  constant  true 
formula. 

A  strand  is  a  ground  strand  if  its  atoms  (the  atoms  occurring  in  its  node 
labels)  are  all  values.  A  (strand)  substitution  is  an  idempotent  map  of  a  subset 
of  X  into  A.  Strand  substitutions  are  extended  to  messages,  formulas,  node 
labels,  and  traces  in  the  usual  way.  A  strand  is  an  instance  of  a  role  r  under 
substitution  a  if  its  trace  is  rer. 

It  is  a  ground  instance  if  the  range  of  a  is  included  in  Z.  A  regidar  strand  is 
an  instance  of  a  protocol  role.  A  penetrator  strand  is  an  instance  of  a  penetrator 
role. 

A  bundle  is  consistent  with  a  protocol  with  roles  { r.j }  if  its  nodes  are  the 
disjoint  union  of  nodesets  of  ground  partial  strands,  such  that  each  strand  is 
either  a  regular  strand  of  some  role  r,  or  a  penetrator  strand.  Furthermore,  we 
require  that 

1.  each  positive  node  formula  is  provable  from  the  (mapped)  initial  theory 
together  with  the  formulas  on  prior  negative  nodes  of  the  strand,  and 

2.  the  bundle  respects  unique  origination. 
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Any  value  of  a  uniquely  originating  parameter  must  be  uniquely  originating 
in  the  bundle  in  the  sense  of  [13].  A  bundle  can  be  consistent  with  a  proto¬ 
col  without  necessarily  satisfying  security  properties  expressed  as  rely  formulas. 
Protocol  verification  establishes  correctness  of  rely  formulas  in  any  bundle  con¬ 
sistent  with  the  protocol. 

1.3  Trust  Management  Formulas 

The  germ  of  the  call-by-contract  idea  was  presaged  in  the  rely-guarantee  trust 
management  approach  described  in  [10].  The  trust  management  formula  as¬ 
sociated  with  a  positive  (send)  node  is  a  guarantee ,  expressed  in  terms  of  the 
protocol  parameters,  that  must  be  provable  for  the  values  bound  to  those  param¬ 
eters.  The  formula  associated  with  a  negative  (receive)  node  is  a  rely  formula, 
which  may  be  assumed  in  proofs  of  subsequent  guarantees.  The  local  theory  of 
a  node  consists  of  the  initial  theory  T  plus  the  rely  formulas  of  prior  nodes  in 
the  role. 

Rely  formulas  are  usually  of  the  form  “p  says  </)” .  These  are  authentication 
goals  whose  validity  must  be  proved  by  the  protocol  designer  as  part  of  the 
verification  of  the  protocol.  The  formula  <f>  is  a  guarantee  that  should  have 
appeared  on  the  send  node  of  a  strand  owned  by  p  that  causally  precedes  the 
receive  node  with  the  rely.  A  strand  is  “owned”  by  a  principal  occurring  as  the 
value  of  a  parameter  p  if  p  is  considered  responsible  for  the  use  of  secret  keys 
needed  to  compose  or  decompose  messages  sent  or  received  by  that  strand.  The 
the  owning  principal  of  each  role  may  be  designated  as  one  of  the  parameters. 


<t> 


+ra 


Figure  1:  Nodes  with  guarantee  and  rely  formulas 

Note  that  guarantees  can  be  active,  in  the  sense  that  they  bind  parameter 
values.  For  example,  a  guarantee  pubkey(a,ka)  may  be  evaluated  in  a  node 
prior  to  which  the  parameter  a  is  bound  but  ka  is  unbound,  and  its  effect  is  to 
look  up  the  public  key  of  principal  a  in  the  local  theory  and  bind  ka  to  it. 
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1.4  General  Services 


A  service  can  be  viewed  as  a  guarantee  that  is  provided  by  a  separate  role  of 
the  same  principal,  like  a  subprotocol.  This  view  is  illustrated  in  Figure  2.  A 
calling  strand  invokes  the  service  with  a  call  that  guarantees  some  precondition 
formula  p  that  implies  the  service  precondition  p' ,  and  the  service  strand  sends 
a  return  annotated  with  another  formula  7'  that  is  the  service  postcondition, 
which  should  imply  the  caller’s  desired  guarantee.  The  call  and  return  messages 
convey  the  sequences  of  values  of  the  input  and  output  parameters  respectively. 
Call  and  return  operators  could  be  modelled  as  additional  operators  in  the 
free  algebra  which  create  private  messages,  in  the  sense  that  they  are  neither 
constructible  nor  analyzable  by  the  attacker.  (They  could  also  be  modeled  using 
the  special  protected  message  directions  introduced  in  [8].) 

There  is  no  need  for  a  “says”  qualification  on  the  returned  rely  because  the 
two  strands  are  owned  by  the  same  principal,  and  the  communication  cannot 
be  seen  or  interfered  with  by  any  attacker. 

Caller  Service 

V  call(x) 

7 - 

V  return(y) 

P  ■< - p 

V 


Figure  2:  Calling  a  service 

The  service  has  a  precondition  and  postcondition,  as  in  the  terminology  of 
the  Eiffel  “design  by  contract”  concept.  Our  focus,  however,  is  not  on  how  the 
service  implements  its  contract,  but  rather  on  how  a  service  selection  mechanism 
can  adapt  a  caller  rely  formula  p  to  a  different  but  sufficient  service  postcondition 
p'  that  was  stated  with  a  different  set  of  formal  parameters.  We  also  need  to 
match  the  caller  guarantee  to  the  service  precondition. 

A  service  is  selectable  for  a  call  request  if  there  exists  a  parameter  mapping 
that  assigns  values  to  service  inputs  from  caller  inputs,  and  caller  outputs  from 
service  outputs,  such  that  the  service  precondition  and  the  caller  postcondition 
are  both  satisfied. 

For  example,  suppose  that  the  caller  requirement  has  precondition  certAuth(z) 
and  its  postcondition  is  pubKey  (a,ka) ,  so  that  its  parameter  set  is  Pc  =  {a,ka,z}. 
The  caller  has  bound  a  and  z  and  needs  a  value  for  ka.  It  might  be  satisfied 
by  a  service  that  asks  for  the  precondition  certAuth(ca)  and  offers  the  post¬ 
condition  pkCert(pk,p,ca),  and  its  parameters  are  Ps  =  {pk,p,ca},  where 
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ca  is  a  certification  authority.  To  match  the  service  to  the  call,  we  must  find 
the  mapping  p  i— >  a,  ka  i— >  pk,  and  ca  i— >  z.  This  match  is  justified  using  an 
inference  rule  like: 

pubKey(A,K)  pkCert (K, A,C) ,  certAuth(C) . 

This  rule  is  presented  in  the  Horn  clause  format  used  in  Datalog  and  Prolog, 
for  reasons  given  in  the  next  subsection.  The  capital  letters  used  as  arguments 
are  logical  variables. 

Where  does  this  inference  rule  come  from?  We  assume  that  there  is  a  selector 
theory  with  conversion  rules  useful  for  translating  between  caller  and  service 
predicate  vocabularies. 

At  this  point  it  is  possible  to  point  out  the  differences  between  the  service 
idea  and  the  prior  related  concepts  of  guarantees  and  subprotocols.  First,  guar¬ 
antees  are  established  logically,  by  inference  from  the  caller’s  local  theory,  while 
the  mechanism  by  which  a  service  establishes  its  postcondition  is  not  specified. 
A  service  postcondition  might  result  from  any  computation,  or  from  a  separate 
protocol. 

A  service  is  different  from  a  subprotocol  because  it  might  just  be  a  local 
computation,  but  even  when  it  is  a  protocol,  the  calling  mechanism  is  different. 
A  subprotocol  call  identifies  a  subprotocol  with  a  known  name  and  parameters, 
while  our  services  are  selectable  through  a  flexible  matching  mechanism  that 
can  search  through  a  list  of  many  subprotocols  to  find  one  that  can  be  made  to 
fit  through  a  suitable  parameter  mapping. 

1.5  Non-Disclosure  Agreements 

One  way  in  which  Figure  2  is  incomplete  is  that  it  does  not  show  that  the 
service  may  participate  in  a  protocol  that  communicates  with  other  principals. 
Parameter  values  that  it  shares  with  the  caller  might  be  transmitted  in  protocol 
messages.  A  caller  might  want  to  insist  that  some  shared  parameter  values  be 
kept  secret,  either  by  not  sending  them  out  at  all,  or  by  sending  them  only 
to  (strands  owned  by)  some  designated  principals.  Specifications  of  this  kind 
must  be  provided  by  the  caller  requirement  and  by  the  service  contract.  Our 
formulation  of  this  kind  of  specification  is  an  “NDA”  and  it  will  be  discussed  in 
Section  4. 


2  Abstraction-Binding  Inferences 

Our  objective  is  not  merely  to  define  the  call-by-contract  relationship,  but  also 
to  describe  a  practical  way  to  implement  the  selection  mechanism  that  matches 
services  to  requests.  The  selection  mechanism  takes  advantage  of  Datalog,  be¬ 
cause  we  have  already  been  using  Datalog  to  support  the  rely-guarantee  trust 
management  approach.  It  has  been  implemented  as  part  of  the  runtime  system 
for  a  high-level  protocol  programming  language,  CPPL  [8]. 
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Datalog  is  a  restricted  form  of  first-order  logic  in  which  each  formula  is  a 
function-free  Horn  clause,  and  every  variable  in  the  head  of  a  clause  must  appear 
in  the  body  of  the  clause.  A  clause  that  meets  this  condition  is  called  a  safe 
clause. 

Datalog  [5]  forms  the  foundation  of  many  deductive  database  systems,  as 
well  as  at  least  one  trust  management  language  [12].  A  Datalog  literal  has 
the  form  predicate-symbolfti,  ...,tk),  where  each  argument  t,  is  either  an  arity- 
zero  function  symbol  (i.e.,  a  constant)  or  a  logical  variable.  The  predicate 
symbols  and  constants  are  application-specific,  and  begin  with  lower-case  letters. 
Variables  begin  with  capital  letters.  In  Datalog,  a  theory  is  a  set  of  safe  Horn 
clauses  of  the  form  head  body  where  the  head  is  a  literal  and  the  body  is  a 
(possibly  empty)  sequence  of  literals.  A  clause  with  an  empty  body  is  a  fact, 
and  a  clause  with  at  least  one  literal  in  the  body  is  a  rule. 

The  conditions  on  asserted  clauses  guarantee  that  the  set  of  all  facts  that  can 
be  derived  from  a  Datalog  theory  is  finite,  and  there  is  a  terminating  algorithm 
to  find  all  provable  instances  of  a  given  literal  presented  as  a  query.  This  is  the 
essential  feature  of  Datalog  for  our  purposes. 

In  order  to  apply  Datalog  to  node  formulas,  we  restrict  ourselves  to  formulas 
that  are  expressible  as  conjunctions  of  Datalog  ground  literals.  We  use  Datalog 
constants  to  represent  atoms,  both  parameters  and  values. 

To  apply  the  Datalog  engine,  we  may  abstract  a  formula  by  replacing  some 
or  all  of  its  parameters  with  fresh,  distinct  variables.  Other  atoms  are  left 
unchanged.  The  abstraction  step  can  be  represented  with  a  substitution  a, 
with  a  domain  given  in  context. 

Now,  suppose  p  and  q  are  formulas,  and  T  is  a  theory  consisting  of  a  set 
of  rules.  We  wish  to  check  whether  some  instance  of  q  follows  from  p  in  the 
context  of  T.  For  now,  assume  that  q  is  a  single  literal.  The  Datalog  engine  is 
used  as  follows: 

1.  assert  T  and  p: 

2.  present  the  abstracted  literal  ga  as  a  query. 

The  engine  will  either  fail  (if  no  instance  of  qa  is  provable),  or  it  will  find 
all  variable  bindings  (3  such  that  qa/3  is  provable  from  T  and  p,  that  is, 

T,p  b  qa/3. 

If  we  let  cr  =  a/3,  we  see  that  we  have  found  a  substitution  a  of  parameters 
into  values  such  that 

T,p  b  qa 

The  combination  of  these  two  steps  is  abstraction  binding. 

Recall  that  A  =  X  U  C,  and  let  A(<j>)  be  the  set  of  atoms  occurring  in 
formula  </>.  Also  let  A(T)  =  \J{A((j))\<j>  occurs  in  T}.  Abstraction  binding  has 
the  following  property: 

Proposition:  Let  T  be  a  constant-free  theory,  consisting  of  rules  such  that 
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A(T)  =  0,  and  let  p  and  q  be  formulas.  Then  abstraction-binding  finds  the  set 
of  all  substitutions  a  on  A(q)  \  A(p)  into  A(p)  such  that  T,p  b  qa.  I 

If  q  is  a  conjunction,  we  can  achieve  the  same  result  by  satisfying  its  conjuncts 
sequentially,  extending  a  as  needed.  (One  way  to  do  this  is  to  introduce  a  new 
predicate  name  for  q ,  and  add  a  rule  for  it  with  the  conjuncts  of  q  serving  as 
the  body.) 

For  convenience,  we  define  the  abstraction-binding  AB  relation  as  follows: 

Definition:  AB  (T,p,  q1  a)  iff  cr  is  a  substitution  on  A(q)  \  A(jp)  into  A(p )  such 
that  T,p  b  qa. 

AB  relations  are  preserved  by  precondition  substitutions. 

Proposition  (AB  Substitution):  If  AB  (T, p,  q,a)  and  r  is  a  substitution  on 
A{p ),  then  AB  ( T,pr,q,ar ). 

This  conclusion  is  valid  because  T  is  constant-free,  so  the  inference  cannot  de¬ 
pend  on  particular  choices  for  the  parameters  of  p.  Another  way  of  thinking 
about  this  is  that  the  parameters  of  p  are  like  Skolem  constants,  since  they  do 
not  occur  in  T .  An  inference  that  holds  with  them  can  be  generalized  to  a 
universal  statement  about  variables  in  their  places,  which  are  then  given  values 
by  r.  I 


3  Selection:  Call  by  Contract 

In  this  section  we  begin  by  looking  at  a  static  specification  of  a  successful  service 
call.  In  a  protocol  with  a  service  call,  the  service  role  is  represented  by  an 
idealization  of  the  service,  in  which  only  the  initial  and  final  nodes  are  present, 
as  in  Figure  2.  A  bundle  containing  a  service  call  instantiates  the  caller  role  rc 
with  some  ground  substitution  ac,  and  the  idealized  service  rs  with  a  ground 
substitution  crs,  which  is  defined  only  on  the  service  parameters  named  in  the 
contract. 

A  request  from  a  caller  has  a  precondition  formula  pc  and  a  postcondition 
formula  qc.  Each  service  has  a  precondition  ps  and  a  postcondition  qs.  With 
the  substitutions  and  the  condition  formulas  just  defined,  Figure  2  turns  into 
Figure  3. 

In  Figure  3,  the  input  and  output  conditions  do  not  have  to  match  exactly, 
but  we  want  them  to  satisfy  the  implications  summarized  in  this  diagram: 

Caller  IK-17,- . >  '/. c,. 

v 

Service  Ps&s  =>  qs&s 

For  any  service,  we  assume  that  it  satisfies  its  contract,  expressed  as  a  pre- 


rcoc 


rs<7s 


V  call(^) 

Pc<?c - ^Ps°s 

v  return  (y)  v 

Qc&c  —  —  —  —  —  —  —  Qs&s 


Figure  3:  General  service  diagram 


condition,  postcondition  pair  (ps,qs).  The  contract  assumes  that  the  service 
has  been  called  with  an  assignment  of  values  to  input  parameters,  which  are 
the  parameters  in  ps.  If  ps  holds  with  these  values,  the  contract  promises  to 
find  values  for  the  output  parameters  (the  parameters  in  qs  that  are  not  input 
parameters)  to  satisfy  qs. 

Notation:  For  a  precondition,  postcondition  pair  (for  either  a  service  or  a 
caller),  it  is  convenient  to  introduce  symbols  for  its  input  parameters  I  =  A(p), 
its  output  parameters  O  =  A{q)  \  A(p ),  and  all  of  its  parameters  P  =  I  U  O. 
Subscripts  s  or  c  will  be  applied  as  needed  in  context. 

Definition:  A  service  contract  is  a  pair  of  node  formulas  ( ps,qs )  such  that 
Ps  C  X  and,  for  all  cr  on  Is  into  Z, 

psa  =>  (3r)  qsaT 


where  r  is  on  Os  into  Z . 

Definition:  A  service  contract  ( ps,qs )  is  independently  selectable  for  caller  re¬ 
quest  ( pc,qc )  if,  for  any  input  substitution  ae  :  Ic  — >  Z ,  there  exist  substitutions 
ac  :  Pc  — >  Z  extending  ae  and  crs  :  Ps  — >  Z  such  that 

1.  T,pcac  b  psas, 

2.  psas  =>  qsas,  and 

3.  T,  qsas  b  qcac. 

The  qualifier  “independently”  reflects  the  condition  that  the  same  service  is 
selectable  regardless  of  which  input  substitution  is  chosen.  Non-independent 
selectability  would  mean  that  a  service  is  selectable  for  some  inputs  but  not 
others.  With  a  constant-free  selector  theory,  we  shall  see  that  independent 
selectability  is  not  only  possible,  but  it  can  be  checked  as  soon  as  the  service 
contract  and  caller  protocol  are  known. 
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3.1  From  the  Static  to  the  Algorithmic  View 

The  purpose  of  a  selection  mechanism  is  to  test  whether  a  given  service,  specified 
by  a  contract,  can  satisfy  a  caller  request  specified  by  a  precondition  pc  and 
postcondition  qc.  Under  the  assumption  that  the  selector  theory  is  constant- 
free,  the  answer  can  be  given  independently  of  the  caller  substitution  ay  in  the 
following  sense.  We  can  give  conditions  on  ay  for  the  existence  of  a  service 
substitution  ay  such  that  the  caller  request  is  satisfied.  The  values  for  the  caller 
precondition  input  parameters  Ic  can  be  arbitrary. 

Theorem  (Selection):  Let  T  be  a  constant-free  theory,  and  suppose  that 
PaQcPsiQs  are  node  formulas  such  that  Pc  is  disjoint  from  Ps.  Assume  that 

1.  oy  .  Ic  ►  Z , 

2.  ( ps ,  qs)  is  a  service  contract, 

3.  AB  ( T,pc,ps,<Ji ),  and 

4.  AB  ( T,qsai,qc,a0 ). 

Then  (ps,qs)  is  independently  selectable  for  ( pClqc )■  Then  there  exists  a  substi¬ 
tution  ay  :  Os  — >  Z  such  that  T,pcae  b  (jyayoyoy. 

Proof:  We  will  find  ay  :  Os  — >  Z  from  which  we  construct  ay  =  oyayoy  and 
(Ts  =  (Ji(Je(Tr . 

We  apply  the  contract  once  and  AB  Substitution  twice.  Hypothesis  3  implies 
that  ay  :  Is  — >  Ic,  and  hypothesis  4  implies  that  oy  :  Oc  — >  Ps. 

By  AB  substitution  on  hypothesis  3  with  ay  :  Ic  —■ >  Z,  we  get  AB  (T,pcoy,p.s,  oyoy). 
This  means  that  T,pcae  b  psoyoy.  By  construction,  the  first  condition  T,pcac  b 
pscrs  is  satisfied. 

Applying  the  contract  in  hypothesis  2,  we  produce  ay  :  Os  — >  Z  such  that 
gyayoyay  holds.  This  satisfies  the  second  condition  ps ay  =>  qsas  by  construction. 

By  AB  substitution  on  hypothesis  4  with  oyay,  we  find  that  T,qsaicrear  b 
Qyoyayoy.  This  gives  us  T,  qsas  b  qcac.  I 

The  way  the  substitutions  are  linked  can  be  traced  in  the  diagram  below. 


Oc 


O 


s 


Is 


G  r 

Y 


The  Selection  Theorem  gives  us  more  than  just  independent  selectability,  since 
it  shows  that  the  caller  and  service  substitutions  can  be  factored  through  input 
and  output  mappings  oy  and  ay.  This  turns  out  to  be  important  later  when  we 
consider  confidentiality  constraints.  The  following  definition  names  this  result. 


Definition:  A  service  contract  ( ps ,  qs)  is  uniformly  selectable  for  caller  request 
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(pcQc)  if,  for  any  input  substitution  ae  :  Ic  — >  Z ,  there  exist  substitutions 
a-i  :  /,  — >  Jc  and  er0  :  Oc  — >  Ps  such  that  independent  selectability  is  satisfied  by 
ac  =  <j0aear  and  as  =  <Jiaear  for  some  crr  :  Os  —>  Z . 

Corollary:  Under  the  conditions  of  the  Selection  Theorem,  (ps ,  qs)  is  uniformly 
selectable  for  (pc,qc)-  B 

The  contract  selection  algorithm  implied  by  the  Selection  Theorem  is  to  consider 
each  available  service  contract  (pSl  qs).  To  test  acceptability  of  a  contract,  apply 
abstraction  binding  to  find  ex,,  and  if  successful,  apply  abstraction  binding  again 
to  find  (7 o .  If  successful  again,  the  service  is  selectable.  Backtracking  or  other 
search  methods  can  explore  multiple  candidates  for  <j0  and  cr, .  If  none  work, 
other  contracts  are  tested. 

Note  that  all  of  this  can  be  done  without  knowing  cre.  At  run  time,  the  service 
is  invoked  with  the  input  substitution  ai.ae.  When  the  service  completes,  caller 
outputs  are  bound  with  a0aear. 

When  multiple  (<Xj,<r0)  solutions  exist,  application  preferences  or  constraints 
can  be  used  to  guide  the  search  order  or  otherwise  choose  among  alternative 
call  mappings.  The  contract  selection  algorithm  as  stated  does  not  yet  consider 
security  constraints,  which  are  discussed  in  the  next  section. 


4  Separate  Verification  of  Protocol  Services 

Our  objective  is  to  separate  the  verification  as  well  as  the  design  and  specifi¬ 
cation  of  services  from  that  of  calling  protocols.  We  need  to  investigate  the 
conditions  under  which  this  is  possible.  In  this  section  we  provide  some  pre¬ 
liminary  issues  and  answers,  though  more  research  is  advised  to  obtain  broader 
results. 

In  the  context  of  the  strand  space  approach,  we  are  concerned  with  authen¬ 
tication  goals,  as  expressed  in  protocol  rely  formulas,  and  confidentiality  goals, 
either  for  their  own  sake,  or  to  support  authentication  proofs. 

Some  issues  regarding  information  flow  are  discussed  first,  then  the  general 
question  of  protocol  separation  is  considered. 

4.1  Information  Flow  Through  Services 

The  implementation  of  a  service  could  affect  the  soundness  of  the  protocol,  if 
it  violates  confidentiality  assumptions.  We  need  to  know  that  the  computation 
implementing  a  service  does  not  cause  information  flows  from  a  secret  input 
parameter  to  an  unprotected  output  parameter. 

For  example,  suppose  that  a  protocol  role  has  a  uniquely  originated,  fresh, 
random  nonce  k  that  we  want  to  keep  secret.  And  suppose  there  is  a  service 
with  contract  (true,  copy(a,b)),  where  copy(a,b)  does  what  it  says,  namely 
to  bind  b  to  the  value  of  a.  If  this  service  is  called  to  obtain  a  postcondition 
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copy(k,m),  and  then  the  caller  sends  m  as  a  message,  the  nonce  k  has  obviously 
been  compromised. 

If  copy  were  just  a  predicate  used  as  a  guarantee,  this  problem  would  surface 
routinely.  The  behavior  of  copy  would  have  to  be  defined  in  the  local  theory. 
The  theory  would  include  a  rule  like  A  =  B  copy(A,B),  and  any  decent 
security  analysis  would  notice  the  consequences. 

However,  a  copy  service  might  be  selected  for  a  caller  whose  local  theory  did 
not  even  possess  an  equality  predicate.  The  caller  might  only  have  requested  a 
weaker  postcondition  like  same_length(k,m) . 

To  use  services  safely,  then,  we  need  to  provide  a  way  for  the  caller  to  spec¬ 
ify  confidentiality  constraints,  and  for  services  to  advertise  their  confidentiality 
promises.  We  also  need  a  way  to  verify  such  promises,  and  to  establish  that  the 
constraints  are  sufficient  to  preserve  the  security  properties  of  the  caller. 

Protocol  analysis  based  on  computational  models  can  determine  whether  ser¬ 
vices  computed  algorithmically  leak  significant  partial  information,  even  when 
they  do  not  actually  lead  to  an  equality  relation.  This  kind  of  analysis  is  dis¬ 
cussed,  for  example,  in  [1],  In  this  paper,  we  just  point  out  that  such  techniques 
exist,  and  our  discussion  on  verifying  confidentiality  will  focus  on  protocols  and 
subprotocols. 

4.2  NDAs 

As  promised  in  Section  1.5,  a  confidentiality  requirement  or  contract  is  expressed 
as  an  NDA  (non-disclosure  agreement).  An  NDA  associates  a  predicate  on 
message  terms  with  each  parameter  of  a  role.  The  NDA  v(x)  of  a  parameter  x 
expresses  a  constraint  on  the  way  x  may  be  released.  The  predicate  formula  is 
not  necessarily  restricted  to  the  language  of  node  formulas. 

In  this  subsection,  we  leave  open  the  semantics  of  v(x).  The  way  in  which 
an  NDA  is  used  will  be  presented,  at  first,  just  formally,  and  then  in  the  next 
subsection  we  provide  a  particular  interpretation  that  justifies  some  security 
conclusions. 

Definition:  A  secure  service  request  is  a  4-tuple  (pc ,  qc,ae ,  v)  of  a  caller  precon¬ 
dition,  a  caller  postcondition,  an  input  value  substitution,  and  an  NDA  defined 
on  the  caller  parameters  Pc.  A  secure  service  contract  is  a  triple  (ps,  qs ,  v)  where 
v  is  defined  on  the  service  parameters  Ps. 

The  contract  (ps,qs,  v)  is  securely  selectable  for  ( pc,qc,ae,u )  if  it  is  uniformly 
selectable  with  parameter  mappings  <Ti,a0  and 

(1)  if  x  £  Is  then  v(x)ai  =>  v(x<Ji)<70  and 

(2)  if  y  G  Oc  then  v{ya0)at  =>  v(y)cr0. 

Condition  (1)  says  that  the  constraint  on  a  service  input  is  stricter  than  the 
constraint  on  the  caller  input  to  which  it  maps.  Condition  (2)  says  that  the 
constraint  on  a  service  output  is  stricter  than  the  constraint  on  any  caller  pa¬ 
rameter  mapped  to  it. 
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The  parameter  mappings  applied  to  the  v  sets  are  necessary  to  make  them 
comparable.  This  is  easy  to  understand  if  one  considers  the  way  terms  are 
mapped  to  values.  With  uniform  selection,  a  caller  term  t  gets  the  value  tac  = 
t<r0aear,  and  a  service  term  t'  gets  the  value  t'crs  =  t'a.icrear.  So  if  taQ  =  t'a, 
then  t  and  t'  are  mapped  to  the  same  value. 

4.3  Example:  Binary  NDA 

Suppose  that  is(x)  is  either  true,  meaning  that  x  is  releasable  without  restric¬ 
tion,  or  false,  meaning  that  x  may  not  be  released  at  all.  There  is  a  triv¬ 
ial  service  contract  (nonce(x) ,  nonce(x)),  and  a  selector  rule  copy(A,A) 
nonce(A)  .  The  secure  service  request  is  (nonce(a) ,  copy(a,b),  creiv)  where  <re 
is  arbitrary  and  v(a)  =  i/(b)  =  false.  Note  that  Ic  =  {a },Oc  =  {b},/s  =  {x}, 
and  Os  =  0.  What  should  the  NDA  of  the  service  be? 

First,  observe  that  the  service  is  uniformly  selectable  with  x<j,;  =  a  and 
b  er0  =  x. 

Applying  the  parameter  mappings,  the  secure  selectability  conditions  be¬ 
come 


(1)  v(a)<Ti  =>•  v(a)cr0  and 

(2)  ^(x)(jj  =>•  i/(b )a0. 

Now  apply  the  v  values  for  the  caller.  Condition  (1)  is  just  false  =  false. 
Condition  (2)  is  ^(xjcq  =  false.  Hence  we  need  v(tl)  =  false.  The  service  is 
being  required  to  keep  its  input  confidential. 

There  is  a  way  to  enforce  binary  NDA  checking  for  free  through  the  basic 
functional  selection  mechanism.  For  each  caller  input  x  such  that  v(x)  is  true, 
add  to  the  initial  theory  the  assertion  public(x).  And  if  v(x )  is  false,  add  the 
assertion  hidden(a:).  Now,  for  both  caller  and  service,  all  public  assertions 
are  added  as  conjuncts  to  preconditions,  and  all  hidden  assertions  are  added  as 
conjuncts  to  postconditions.  Thus,  if  a  service  treats  an  input  as  public,  that 
will  automatically  be  justified,  as  part  of  the  selectability  check,  by  checking 
that  the  caller  input  it  maps  to  is  public;  and  if  a  caller  believes  that  an  output 
is  hidden,  that  will  be  justified  by  checking  that  the  service  treats  the  parameter 
it  maps  to  as  hidden. 

4.4  Services  Implemented  as  Protocols 

Many  useful  services  are  implemented  as  protocols  that  exchange  messages  with 
a  third  party.  For  example,  a  service  might  check  certificate  revocation  by 
contacting  a  validation  authority.  The  “third”  party  might  also  be  a  party 
already  participating  in  the  main  protocol,  if  the  service  performs  some  standard 
negotiation.  Figure  4  illustrates  a  protocol  service  that  exchanges  messages 
m,m'  with  an  instance  of  a  role  r* .  The  dotted  transitions  indicate  that  the 
service  might  go  through  several  nodes  before  returning  to  the  caller. 

Ordinarily,  a  protocol  soundness  proof  for  a  protocol  that  invokes  a  sub¬ 
protocol  would  consider  the  protocol  and  subprotocol  together,  verifying  the 
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Figure  4:  Protocol  Service  Call 


composition  as  a  single  larger  protocol.  However,  we  wish  to  take  advantage 
of  prior  work  that  identifies  conditions  under  which  protocol  components  may 
be  verified  in  isolation,  preserving  their  security  properties  when  they  are  com¬ 
bined. 

Protocols  may  be  combined  in  two  senses.  One  is  by  refinement,  which  is 
close  to  the  idea  of  a  service:  a  protocol  needs  some  function  accomplished,  and 
the  objective  is  to  prove  its  correctness  and  security  while  treating  the  function 
as  a  black  box.  Then  the  function  is  later  expanded  into  a  subprotocol,  which 
is  verified  separately.  One  thread  of  research  that  has  taken  this  approach  with 
sufficient  formality  and  attention  to  security  in  a  Dolev-Yao  modeling  context 
is  represented  by  Datta,  et  al.  [6]  Their  composition  methodology,  however, 
requires  one  to  identify  invariants  used  in  the  proofs  of  different  protocol  com¬ 
ponents,  and  check  that  each  component  satisfies  the  other’s  invariant  as  well 
as  its  own.  This  approach  does  not,  in  this  general  form,  facilitate  our  objective 
for  independent  design  and  verification  of  services  and  the  protocols  using  them. 

Protocols  are  also  combined,  in  a  sense,  when  they  are  run  independently 
in  the  same  attacker  environment,  either  concurrently  or  sequentially.  Many 
papers  have  noted  that  it  is  possible  for  protocols  to  interfere  with  one  another, 
invalidating  security  properties  proved  in  isolation,  when  the  same  principal 
(using  the  same  long-term  private  keys)  participates  in  more  than  one  protocol. 
Papers  on  this  topic,  with  varying  degrees  of  formality,  go  back  at  least  to  [11] 
and  include  [4]  and  [9].  Universal  composability  [3]  is  a  strong  property  in  the 
computational  arena  that  can  also  lead,  for  some  protocols,  to  preservation  of 
security  in  a  multiprotocol  environment. 

How  could  we  use  independent  composition  to  verify  services?  The  idea  is 
to  treat  the  caller  request  as  a  pair  of  guarantees,  rather  than  as  a  guarantee 
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for  the  precondition  and  a  rely  for  the  postcondition.  It  can  then  be  verified 
separately.  The  service  is  a  separate  protocol  anyway,  its  only  dependence  to 
the  caller  being  the  choice  of  input  values.  However,  some  additional  conditions 
will  be  necessary  to  prevent  interference  that  would  undermine  security.  Those 
conditions  can  be  reflected  in  the  choice  of  NDA  and  its  semantics. 

To  give  an  example  of  a  particular  result  along  these  lines,  we  apply  the 
protocol  independence  theorem  from  [9].  The  definitions  are  reviewed  here, 
though  [9]  should  be  consulted  for  more  details. 

4.5  Review  of  Protocol  Independence 

The  results  concern  a  strand  space  E  consisting  of  regular  strands  Ei  of  a  pri¬ 
mary  protocol  (think  of  this  as  the  caller),  regular  strands  of  another  secondary 
protocol  (from  services),  and  penetrator  strands.  The  following  definitions  are 
needed. 

Definitions:  A  strand  space  E  is  fidl  if  every  atomic  value  a  that  originates  on 
any  secondary  strand  in  E  also  originates  on  a  penetrator  strand  in  E. 

An  atom  a  is  private  if  it  originates  uniquely  only  in  Ei. 

A  term  t  occurs  in  a  term  t' ,  written  t  C  t' ,  if  it  is  a  subterm,  but  not  in  the  key 
part  of  an  encryption.  A  term  occurs  in  a  node  if  it  occurs  in  its  message.  A 
component  of  a  non-pair  term  is  the  whole  term,  and  a  pair  t ,  t'  has  components 
t  and  t' .  A  “new  component”  of  a  node  is  a  term  that  has  not  occurred  as  a 
subterm  of  a  prior  node  (by  =>)  in  the  same  strand. 

E  has  disjoint  outbound  encryption  if  and  only  if  the  following  holds.  Let  rii  G  Ej 
be  a  positive  node,  let  ri2  £  E2  be  a  negative  node,  and  let  a  be  a  private  atom 
occurring  in  some  encrypted  term  {Ii}k,  where  {ft} k  C  rii  and  {ft} k  C  712. 
Then  there  is  no  positive  n'2  such  that  ?i2  =>+  n'2  and  a  occurs  in  a  new  compo¬ 
nent  of  n2. 

E  has  disjoint  inbound  encryption  if,  for  any  negative  node  ni  G  Ej  and  positive 
node  ri2  G  S2  in  which  an  encrypted  term  {h}k  occurs,  {ft}fc  does  not  occur  in 
any  new  component  of  712  • 

Two  bundles  over  E  are  equivalent  if  they  have  the  same  Ei  nodes.  Ei  is  inde¬ 
pendent  of  E2  if  every  bundle  over  E  is  equivalent  to  one  with  no  E2  nodes. 

Theorem  (Protocol  Independence,  Prop.  7.2  in  [9]):  If  E  is  full  and  has 
both  disjoint  inbound  and  disjoint  outbound  encryption,  then  Ei  is  independent 
of  S2. 

The  significance  of  protocol  independence  is  that  any  attack  on  an  authenti¬ 
cation  property  that  is  possible  in  the  E  multiprotocol  strand  space  can,  by 
equivalence,  be  reproduced  without  E2  strands,  and  hence  should  have  been 
excluded  by  a  verification  of  the  primary  protocol  in  isolation. 
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4.6  Application  of  Protocol  Independence 

The  idea  behind  disjoint  inbound  and  outbound  encryption  is  that  a  secondary 
protocol  should  not  alter  or  repackage  any  encrypted  term  that  either  originated 
in  the  primary  protocol  or  could  be  received  by  it.  It  was  observed  in  [9]  (and 
the  idea  was  also  suggested  in  other  papers)  that  a  protocol  identifier  could  be 
included  in  every  encrypted  term  that  was  produced  by  a  particular  protocol, 
so  that  a  party  that  received  a  term  encrypted  by  a  confidential  key  would  be 
able  to  check  that  it  was  produced  in  its  own  protocol.  All  roles  of  the  same 
protocol  would  use  the  same  identifier,  but  a  different  (secondary  or  service) 
protocol  would  use  a  different  identifier.  Use  of  protocol  identifiers  in  this  way 
would  guarantee  disjoint  inbound  and  outbound  encryption. 

To  apply  the  protocol  independence  theorem,  we  also  need  the  “full”  prop¬ 
erty.  The  “full”  condition  requires  that  a  confidential  atom  originating  in  the 
primary  protocol  may  not  also  originate  in  the  secondary  protocol.  This  is  a 
problem  when  the  atom  is  passed  as  an  input  parameter  to  a  service,  since  pa¬ 
rameters  that  are  not  received  in  a  message  appear  to  originate  in  the  service. 
However,  we  can  use  an  NDA  to  fix  this. 

If  a  parameter  a  is  uniquely  originating  in  the  calling  protocol,  and  it  is 
provided  as  an  input  to  a  service,  we  can  list  the  encrypted  terms  in  which  it 
occurs.  Let  i'(a)  be  a  predicate  that  tests  membership  in  that  list.  A  service 
with  a  compatible  NDA  for  a  parameter  mapped  to  a  recognizes  a  smaller  list 
of  terms  that  will  be  mapped  to  the  same  ground  terms.  The  semantics  of  the 
NDA  for  service  is  the  same:  it  specifies  the  set  of  “safe”  terms  in  which  a 
confidential  parameter  may  occur.  This  means  that  the  confidential  parameter 
will  be  transmitted  only  in  terms  that  can  be  traced  back  to  terms  originating 
in  the  caller.  The  full  property  is  then  satisfied  for  those  parameters. 

The  “full”  condition  also  prevents  a  confidential  value  from  being  generated 
by  the  service,  since  a  confidential  return  parameter  cannot  be  recognized  as 
“private”.  This  limits  the  applicability  of  the  protocol  independence  result. 

Note  that,  if  we  use  protocol  identifiers,  use  NDAs  to  limit  private  atom  con¬ 
texts,  and  refrain  from  generating  confidential  values  in  services  to  be  returned 
to  the  caller,  the  conditions  for  protocol  independence  apply  between  different 
services  as  well  as  between  the  caller  and  its  services. 

To  summarize: 

Corollary:  Under  the  following  conditions,  a  calling  protocol  and  its  services 
preserve  authentication  properties  when  verified  independently: 

1.  each  protocol  (and  service)  includes  a  different  protocol  identifier  in  en¬ 
crypted  terms  constructed  by  that  protocol; 

2.  each  service  respects  its  promised  NDA,  in  that  each  parameter  x  may 
occur  only  in  components  of  sent  messages  satisfying  v(x)\ 

3.  no  service  originates  a  confidential  atom  returned  to  the  caller. 


5  Conclusion 


Call  by  contract  is  a  way  to  specify  and  use  interchangeable  services  in  secure 
protocols,  so  that  protocols  and  services  can  be  independently  designed  and 
verified.  The  interface  to  a  service  is  specified  with  a  precondition  and  postcon¬ 
dition  as  in  an  Eiffel  contract.  However,  to  facilitate  independent  design,  the 
calling  protocol  requests  a  service  with  its  own  precondition  and  postcondition. 
The  calling  protocol  need  not  know  the  name  of  the  service  or  its  parameter 
list. 

A  selection  algorithm  is  given  to  test  whether  a  candidate  service  is  uniformly 
selectable.  Uniform  selection  implies  the  existence  of  parameter  mappings  be¬ 
tween  the  caller  and  service  such  that  the  preconditions  and  postconditions  are 
sufficient,  independently  of  the  particular  input  parameter  values.  The  selec¬ 
tion  algorithm  is  based  on  a  technique  called  abstraction  binding,  employing  a 
Datalog  engine. 

To  facilitate  independent  security  verification  of  the  calling  protocol  and 
its  services,  contracts  and  requests  also  provide  an  NDA.  Informally,  NDAs 
are  confidentiality  constraints  on  parameters.  Formally,  NDAs  of  caller  and 
service  are  compared  in  a  straightforward  way  for  “secure”  select  ability.  The 
semantics  of  NDAs,  and  any  proof  that  secure  selectability  enables  independent 
verification,  are  not  fixed,  and  can  be  interpreted  differently  in  different  protocol 
modeling  contexts.  We  have  given  an  example  of  NDA  semantics  that  yields 
some  limited  independence,  but  stronger  results,  and  different  interpretations 
and  results  in  other  contexts,  should  be  possible  in  the  future. 

We  have  an  experimental  prototype  implementation  of  the  service  algorithm 
to  support  CPPL,  our  protocol  compiler  that  makes  use  of  a  Datalog  runtime 
engine.  This  prototype  is  still  under  development. 
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A  Implementation  Notes 

Notes  on  our  implementation  of  the  selector  algorithm  follow.  The  imple¬ 
mentation  follows  the  algorithm  in  Section  3  except  that  it  combines  the  two 
abstraction-binding  steps  into  a  single  Datalog  query.  This  is  facilitated  by 
adding  rules  expressing  the  contract. 

Let  S(<j))  be  a  sequence  of  the  parameters  in  formula  f>.  Each  parameter  in 
S((f>)  occurs  once,  and  the  parameters  are  ordered  by  their  first  appearance  in 
the  formula.  Let  V(X)  be  a  sequence  of  distinct  variables  of  the  same  length 
as  X.  (V(X)  can  be  the  X-length  initial  subsequence  of  a  long  fixed  variable 
sequence.)  Let  r  ::  X  be  the  literal  constructed  from  predicate  symbol  r  and 
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the  sequence  of  terms  X.  Let  p[X]  be  the  formula  in  which  each  parameter 
in  X  is  replaced  in  p  by  its  corresponding  variable  in  V(X).  Thus,  p[X]  is 
an  abstraction  of  p  over  a  specific  set  of  parameters.  The  concatenation  of 
sequences  Xi  and  X2  is  Xi  ■  X2.  The  subsequence  of  X\  elements  that  are  not 
in  X2  is  Xl  \  X2. 

Note  that,  in  general,  a  substitution  a  on  a  set  X  can  be  represented  with 
respect  to  an  ordering  X  by  a  result  vector  Y  such  that  cr(x)  =  Y (X_1(a;)).  We 
write  a  =  Y / X.  If  substitutions  cq  =  Yj/Xi  have  disjoint  domains,  ay  U  cr2  = 
Y\  ■  Y2/X\  ■  X2.  Also,  (a  o  r)(x)  =  a(r( x))  and  (a  o  X)(i)  =  a(X(i)). 

A  contract  in  the  implementation  is  a  5-tuple  (ps,  qs,  Is,Os,  s),  where  s  is  the 
name  of  the  procedure  that  implements  the  service.  The  service  contract  of  s 
is  ( ps,qs ),  the  input  parameter  sequence  of  s  is  /s,  and  the  output  parameter 
sequence  of  s  is  Os. 

A  caller  provides  a  triple  (pClqc,  Zc),  where  the  caller’s  pre-  and  postcon¬ 
dition  are  ( pc,qc ),  and  the  values  associated  with  the  parameters  in  S(pc)  are 
given  by  Zc.  Thus,  cre  =  Zc/Ic  for  Ic  =  S(pc).  A  call  is  ill- formed  if  the  length 
of  Zc  differs  from  the  length  of  Ic.  Let  Oc  =  S(qc )  \  S(pc). 

If  the  selector  algorithm  determines  that  a  service  s  is  selectable,  and  then 
selects  it,  it  invokes  the  service  with  a  sequence  of  input  values  Zs  and  a  sequence 
of  natural  numbers  Ns.  Ns  is  defined  below;  it  tells  the  service  which  values  to 
return,  and  in  which  order,  corresponding  to  caller  outputs. 

The  selector  algorithm  is  the  following. 

1.  Rename  parameters  in  the  service  contract  to  ensure  that  service  param¬ 
eters  do  not  occur  in  caller’s  formulas. 

2.  Assert  each  literal  in  pc. 

3.  Recall  that  a  formula  is  a  conjunction  of  literals,  and  let  <f>1  be  the  i-th 
literal.  For  each  literal  in  gs[/s],  assert  gs[/s]  :  -ps[Is}.  If  any  clause  is  not 
safe,  the  service  s  is  not  selectable.  These  rules  represent  the  contract. 

4.  Let  r  be  afresh  predicate  symbol.  Assert  r::V(Is-Oc ) :  -ps[Is-Oc],  qc[Is-Oc}. 
If  the  clause  is  not  safe,  the  service  s  is  not  selectable. 

5.  If  an  instance  of  r  ::  V(IS  ■  Oc )  is  derivable,  the  service  s  is  selectable. 

Let  r  ::IS  ■  Oc  be  a  derived  instance  of  r  ::V (I s  •  Oc).  The  input  values  Zs 
required  by  the  service  are  obtained  as  ( Zc/Ic )  o  (Is/Is)  o  Is.  The  number 
sequence  Ns  given  to  the  service  is  obtained  as  (Is  ■  Os)_1  o  Oc. 

The  service  then  executes  and  produces  its  own  output  values  Z0.  It  then 
produces  the  sequence  of  values  for  caller  outputs  as  Zs  ■  Za  o  Ns. 
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